Virtualização de Descritores de Arquivo WebAssembly WASI: Desbloqueando a Abstração Universal de Recursos

No cenário em rápida evolução da computação distribuída, a busca por aplicações que sejam simultaneamente seguras, altamente portáteis e incrivelmente eficientes tornou-se primordial. Desenvolvedores e arquitetos em todo o mundo lidam com desafios impostos por sistemas operacionais heterogêneos, diversas arquiteturas de hardware e a necessidade constante de limites de segurança robustos. Este desafio global levou ao surgimento do WebAssembly (Wasm) e sua interface de sistema, WASI (WebAssembly System Interface), como uma poderosa mudança de paradigma.

No cerne da inovação do WASI reside um mecanismo sofisticado conhecido como Virtualização de Descritores de Arquivo, um conceito que sustenta sua promessa de abstração universal de recursos. Esta postagem do blog aprofunda-se neste aspecto crítico, explicando como o WASI aproveita descritores de arquivo virtuais para abstrair detalhes específicos do host, capacitando assim os módulos WebAssembly a interagir com o mundo exterior de maneira altamente segura, portátil e eficiente, independentemente da infraestrutura subjacente.

O Desafio Duradouro: Unindo Código e Recursos Concretos

Antes de dissecarmos a solução do WASI, é essencial entender o problema fundamental que ele aborda. As aplicações de software, independentemente de sua complexidade, inevitavelmente precisam interagir com recursos externos. Isso inclui ler e gravar arquivos, enviar e receber dados por redes, acessar a hora atual, gerar números aleatórios ou consultar variáveis de ambiente. Tradicionalmente, essas interações são realizadas por meio de chamadas de sistema – funções específicas fornecidas pelo kernel do sistema operacional (SO).

O Dilema "Nativo": Interfaces Específicas do SO e Riscos Inerentes

Considere um programa escrito em C ou Rust projetado para salvar dados em um arquivo. Em um sistema Linux, ele pode usar funções padrão POSIX como open(), write() e close(). Em um sistema Windows, ele empregaria APIs Win32 como CreateFile(), WriteFile() e CloseHandle(). Essa nítida divergência significa que o código escrito para um SO geralmente requer modificações significativas ou implementações inteiramente diferentes para ser executado em outro. Essa falta de portabilidade cria uma sobrecarga substancial de desenvolvimento e manutenção para aplicações que visam um público global ou diversos ambientes de implantação.

Além da portabilidade, o acesso direto às chamadas de sistema apresenta vulnerabilidades de segurança significativas. Uma aplicação maliciosa ou comprometida, com acesso irrestrito a toda a gama de chamadas de sistema do SO, poderia potencialmente:

• Acessar qualquer arquivo no sistema: Ler arquivos de configuração sensíveis ou escrever código malicioso em binários críticos do sistema.
• Abrir conexões de rede arbitrárias: Lançar ataques de negação de serviço ou exfiltrar dados.
• Manipular processos do sistema: Terminar serviços essenciais ou iniciar novos processos não autorizados.

Estratégias de contenção tradicionais, como máquinas virtuais (VMs) ou contêineres (como Docker), oferecem uma camada de isolamento. No entanto, as VMs acarretam uma sobrecarga significativa, e os contêineres, embora mais leves, ainda dependem de recursos compartilhados do kernel e exigem configuração cuidadosa para evitar "escapes de contêiner" ou acesso superprivilegiado. Eles fornecem isolamento no nível do processo, mas não necessariamente no nível de recurso granular que Wasm e WASI visam.

O Imperativo do "Sandbox": Segurança Sem Sacrificar a Utilidade

Para ambientes modernos, não confiáveis ou multi-inquilinos – como plataformas serverless, dispositivos de borda ou extensões de navegador – é necessária uma forma de sandboxing muito mais rigorosa e granular. O objetivo é permitir que um pedaço de código execute sua função pretendida sem conceder-lhe qualquer poder ou acesso desnecessário a recursos que ele não precise explicitamente. Este princípio, conhecido como o princípio do menor privilégio, é fundamental para um design de segurança robusto.

WebAssembly (Wasm): O Formato Binário Universal

Antes de nos aprofundarmos nas inovações do WASI, vamos recapitular brevemente o próprio WebAssembly. Wasm é um formato de bytecode de baixo nível projetado para aplicações de alto desempenho. Ele oferece várias vantagens atraentes:

• Portabilidade: O bytecode Wasm é agnóstico em relação à plataforma, o que significa que pode ser executado em qualquer sistema que possua um runtime Wasm, independentemente da arquitetura de CPU ou sistema operacional subjacente. Isso é semelhante ao "escreva uma vez, execute em qualquer lugar" do Java, mas em um nível muito mais baixo, mais próximo do desempenho nativo.
• Desempenho: O Wasm é projetado para velocidade de execução quase nativa. Ele é compilado em código de máquina altamente otimizado pelo runtime Wasm, tornando-o ideal para tarefas intensivas em CPU.
• Segurança: O Wasm é executado em um sandbox seguro e com segurança de memória por padrão. Ele não pode acessar diretamente a memória ou os recursos do sistema host, a menos que seja explicitamente concedida permissão pelo runtime Wasm.
• Independência de Linguagem: Desenvolvedores podem compilar código escrito em várias linguagens (Rust, C/C++, Go, AssemblyScript e muitas outras) para Wasm, permitindo o desenvolvimento poliglota sem dependências de runtime específicas da linguagem.
• Baixa Ocupação: Módulos Wasm são tipicamente muito pequenos, resultando em downloads mais rápidos, menor consumo de memória e tempos de inicialização mais rápidos, o que é crucial para ambientes de borda e serverless.

Embora o Wasm forneça um ambiente de execução poderoso, ele é inerentemente isolado. Ele não possui capacidades incorporadas para interagir com arquivos, redes ou outros recursos do sistema. É aqui que o WASI entra em jogo.

WASI: Unindo WebAssembly e o Sistema Host com Precisão

WASI, ou WebAssembly System Interface, é uma coleção modular de APIs padronizadas que permitem que módulos WebAssembly interajam de forma segura com ambientes host. Ele é projetado para ser agnóstico em relação ao SO, permitindo que os módulos Wasm alcancem verdadeira portabilidade fora do navegador.

O Papel das Interfaces de Sistema: Um Contrato para Interação

Pense no WASI como um contrato padronizado. Um módulo Wasm escrito para a especificação WASI sabe exatamente quais funções pode chamar para solicitar recursos do sistema (por exemplo, "abrir um arquivo", "ler de um socket"). O runtime Wasm, que hospeda e executa o módulo Wasm, é responsável por implementar essas funções WASI, traduzindo as solicitações abstratas em operações concretas no SO host. Essa camada de abstração é a chave para o poder do WASI.

Princípios de Design do WASI: Segurança Baseada em Capacidades e Determinismo

O design do WASI é fortemente influenciado pela segurança baseada em capacidades. Em vez de um módulo Wasm ter uma permissão genérica para executar certas ações (por exemplo, "todo o acesso a arquivos"), ele recebe apenas "capacidades" específicas para recursos específicos. Isso significa que o host concede explicitamente ao módulo Wasm apenas as permissões exatas de que ele precisa para um conjunto limitado de recursos. Este princípio minimiza drasticamente a superfície de ataque.

Outro princípio crucial é o determinismo. Para muitos casos de uso, especialmente em áreas como blockchain ou builds reprodutíveis, é vital que um módulo Wasm, dados os mesmos inputs, sempre produza o mesmo output. O WASI é projetado para facilitar isso, fornecendo comportamentos bem definidos para chamadas de sistema, reduzindo o não-determinismo onde possível.

Virtualização de Descritores de Arquivo: Uma Análise Profunda na Abstração de Recursos

Agora, vamos ao cerne da questão: como o WASI alcança a abstração de recursos através da virtualização de descritores de arquivo. Este mecanismo é central para a promessa de segurança e portabilidade do WASI.

O Que é um Descritor de Arquivo? (A Visão Tradicional)

Em sistemas operacionais tradicionais tipo Unix, um descritor de arquivo (FD) é um indicador abstrato (tipicamente um inteiro não negativo) usado para acessar um arquivo ou outro recurso de entrada/saída, como um pipe, um socket ou um dispositivo. Quando um programa abre um arquivo, o SO retorna um descritor de arquivo. O programa então usa este FD para todas as operações subsequentes naquele arquivo, como leitura, escrita ou busca. FDs são fundamentais para como os processos interagem com o mundo exterior.

O problema com os FDs tradicionais, da perspectiva do Wasm, é que eles são específicos do host. Um número de FD em um SO pode corresponder a um recurso inteiramente diferente, ou mesmo ser inválido, em outro. Além disso, a manipulação direta de FDs do host ignora qualquer sandboxing, dando ao módulo Wasm acesso irrestrito.

Descritores de Arquivo Virtuais do WASI: A Camada de Abstração

O WASI introduz seu próprio conceito de descritores de arquivo virtuais. Quando um módulo Wasm, compilado com WASI, precisa interagir com um arquivo ou um socket de rede, ele não interage diretamente com os descritores de arquivo do SO host. Em vez disso, ele faz uma requisição ao runtime WASI usando uma API definida pelo WASI (por exemplo, wasi_snapshot_preview1::fd_read).

Veja como funciona:

1. Pré-abertura pelo Host: Antes mesmo do módulo Wasm iniciar a execução, o ambiente host (o runtime Wasm) "pré-abre" explicitamente diretórios ou recursos específicos para o módulo. Por exemplo, o host pode decidir que o módulo Wasm só pode acessar arquivos dentro de um diretório específico, digamos /my-data, e conceder-lhe acesso somente leitura.
2. Atribuição de FD Virtual: Para cada recurso pré-aberto, o host atribui um descritor de arquivo virtual (um inteiro) que é significativo *apenas dentro do sandbox do módulo Wasm*. Esses FDs virtuais são tipicamente 3 ou superiores, pois os FDs 0, 1 e 2 são convencionalmente reservados para entrada padrão, saída padrão e erro padrão, respectivamente, que também são virtualizados pelo WASI.
3. Concessão de Capacidades: Juntamente com o FD virtual, o host também concede um conjunto específico de capacidades (permissões) para esse FD virtual. Essas capacidades são granulares e especificam exatamente quais ações o módulo Wasm pode executar naquele recurso. Por exemplo, um diretório pode ser pré-aberto com um FD virtual (por exemplo, 3) e capacidades para leitura, escrita, e criação_de_arquivo. Outro arquivo pode ser pré-aberto com FD virtual 4 e apenas a capacidade de leitura.
4. Interação do Módulo Wasm: Quando o módulo Wasm deseja ler de um arquivo, ele chama uma função WASI como wasi_snapshot_preview1::path_open, especificando um caminho relativo a um de seus diretórios pré-abertos (por exemplo, "data.txt" relativo ao FD virtual 3). Se bem-sucedido, o runtime WASI retorna *outro* FD virtual para o arquivo recém-aberto, juntamente com suas capacidades específicas. O módulo então usa este novo FD virtual para operações de leitura/escrita.
5. Mapeamento do Host: O runtime Wasm no host intercepta essas chamadas WASI. Ele consulta o FD virtual, verifica a ação solicitada contra as capacidades concedidas e então traduz esta solicitação virtual para a chamada de sistema *nativa* correspondente no SO host, usando o descritor de arquivo real e subjacente do host ao qual o recurso pré-aberto mapeia.

Todo este processo acontece de forma transparente para o módulo Wasm. O módulo Wasm apenas vê e opera em seus descritores de arquivo virtuais abstratos e nas capacidades associadas a eles. Ele não tem conhecimento da estrutura subjacente do sistema de arquivos do host, seus FDs nativos ou suas convenções específicas de chamadas de sistema.

Exemplo Ilustrativo: Pré-abertura de um Diretório

Imagine um módulo Wasm projetado para processar imagens. O ambiente host pode iniciá-lo com um comando como:

wasmtime --mapdir /in::/var/data/images --mapdir /out::/tmp/processed-images image-processor.wasm

Neste cenário:

• O runtime Wasm do host (por exemplo, Wasmtime) pré-abre dois diretórios do host: /var/data/images e /tmp/processed-images.
• Ele mapeia /var/data/images para o caminho virtual do módulo Wasm /in, e concede a ele, digamos, capacidades de leitura e consulta. Isso significa que o módulo Wasm pode listar e ler arquivos dentro de seu diretório virtual /in.
• Ele mapeia /tmp/processed-images para o caminho virtual do módulo Wasm /out, e concede a ele, digamos, capacidades de escrita, criação_de_arquivo e remoção_de_arquivo. Isso permite que o módulo Wasm grave imagens processadas em seu diretório virtual /out.
• O módulo Wasm, quando solicitado a abrir /in/picture.jpg, recebe um FD virtual para esse arquivo. Ele pode então ler os dados da imagem usando esse FD virtual. Quando termina o processamento e deseja salvar o resultado, ele abre /out/picture-processed.png, recebe outro FD virtual e o usa para escrever o novo arquivo.

O módulo Wasm está completamente alheio ao fato de que /in no host é na verdade /var/data/images ou que /out é /tmp/processed-images. Ele apenas conhece seu sistema de arquivos virtualizado e em sandbox.

Implicações Práticas e Benefícios para um Ecossistema Global

A beleza da virtualização de descritores de arquivo do WASI estende-se muito além da mera elegância técnica; ela desbloqueia benefícios profundos para desenvolvedores e organizações que operam em um cenário tecnológico globalmente diverso:

1. Segurança Incomparável: O Princípio do Menor Privilégio em Ação

Este é, sem dúvida, o benefício mais significativo. Através da pré-abertura explícita pelo host e da concessão de capacidades, o WASI impõe rigorosamente o princípio do menor privilégio. Um módulo Wasm pode acessar apenas o que lhe foi dado. Ele não pode:

• Escapar de seus diretórios designados: Um módulo destinado a acessar /data não pode subitamente tentar ler /etc/passwd.
• Realizar operações não autorizadas: Um módulo com acesso somente leitura não pode escrever ou excluir arquivos.
• Acessar recursos não concedidos explicitamente: Se não for pré-aberto, é inacessível. Isso elimina muitos vetores de ataque comuns e torna os módulos Wasm significativamente mais seguros de executar, mesmo de fontes não confiáveis. Este nível de segurança é crucial para ambientes multi-inquilinos como a computação serverless, onde o código de diferentes usuários é executado na mesma infraestrutura.

2. Portabilidade Aprimorada: Escreva Uma Vez, Execute Verdadeiramente em Qualquer Lugar

Como o módulo Wasm opera puramente em descritores de arquivo virtuais abstratos e APIs WASI, ele se torna totalmente desacoplado do sistema operacional host subjacente. O mesmo binário Wasm pode ser executado sem problemas em:

• Servidores Linux (usando runtimes `wasmedge`, `wasmtime` ou `lucet`).
• Máquinas Windows (usando runtimes compatíveis).
• Estações de trabalho macOS.
• Dispositivos de borda (como Raspberry Pi ou até microcontroladores com runtimes especializados).
• Ambientes de nuvem (em várias máquinas virtuais ou plataformas de contêineres).
• Sistemas embarcados personalizados que implementam a especificação WASI.

O runtime do host lida com a tradução dos FDs e caminhos virtuais do WASI para as chamadas de SO nativas. Isso reduz drasticamente o esforço de desenvolvimento, simplifica os pipelines de implantação e permite que as aplicações sejam implantadas no ambiente mais ideal sem recompilação ou reengenharia.

3. Isolamento Robusto: Prevenindo Movimento Lateral e Interferência

A virtualização do WASI cria fortes limites de isolamento entre os módulos Wasm e o host, e também entre diferentes módulos Wasm executando-se concorrentemente. O mau funcionamento ou comprometimento de um módulo não pode se espalhar facilmente para outras partes do sistema ou para outros módulos. Isso é particularmente valioso em cenários onde múltiplos plugins não confiáveis ou funções serverless compartilham um único host.

4. Implantação e Configuração Simplificadas

Para equipes de operações globalmente, o WASI simplifica a implantação. Em vez de precisar configurar orquestrações complexas de contêineres com montagens de volume e contextos de segurança específicos para cada aplicação, eles podem simplesmente definir os mapeamentos e capacidades explícitas de recursos na invocação do runtime Wasm. Isso leva a implantações mais previsíveis e auditáveis.

5. Maior Composibilidade: Construindo a partir de Blocos Seguros e Independentes

As interfaces claras e o forte isolamento fornecidos pelo WASI permitem que os desenvolvedores construam aplicações complexas compondo módulos Wasm menores e independentes. Cada módulo pode ser desenvolvido e protegido isoladamente, e então integrado sabendo que seu acesso a recursos é estritamente controlado. Isso promove arquitetura modular, reusabilidade e manutenibilidade.

Abstração de Recursos na Prática: Além dos Arquivos

Embora o termo "Virtualização de Descritores de Arquivo" possa sugerir um foco exclusivo em arquivos, a abstração de recursos do WASI se estende a muitos outros recursos fundamentais do sistema:

1. Sockets de Rede

De forma semelhante aos arquivos, o WASI também virtualiza as operações de sockets de rede. Um módulo Wasm não pode abrir arbitrariamente qualquer conexão de rede. Em vez disso, o runtime do host deve conceder-lhe explicitamente permissão para:

• Vincular a endereços e portas locais específicos: Por exemplo, apenas a porta 8080.
• Conectar a endereços e portas remotos específicos: Por exemplo, apenas a api.example.com:443.

O módulo Wasm solicita um socket (recebendo um FD virtual), e o runtime do host gerencia a conexão TCP/UDP real. Isso impede que um módulo malicioso escaneie redes internas ou lance ataques externos.

2. Relógios e Temporizadores

Acessar a hora atual ou configurar temporizadores é outra interação que o WASI abstrai. O host fornece um relógio virtual ao módulo Wasm, que pode consultar a hora ou configurar um temporizador sem interagir diretamente com o relógio de hardware do host. Isso é importante para o determinismo e para evitar que os módulos manipulem a hora do sistema.

3. Variáveis de Ambiente

Variáveis de ambiente frequentemente contêm dados de configuração sensíveis (por exemplo, credenciais de banco de dados, chaves de API). O WASI permite que o host forneça explicitamente *apenas* as variáveis de ambiente necessárias ao módulo Wasm, em vez de expor todas as variáveis de ambiente do host. Isso evita vazamento de informações.

4. Geração de Números Aleatórios

A geração de números aleatórios criptograficamente seguros é crítica para muitas aplicações. O WASI fornece uma API para que os módulos Wasm solicitem bytes aleatórios. O runtime do host é responsável por fornecer números aleatórios de alta qualidade e gerados com segurança, abstraindo as especificidades do gerador de números aleatórios do host (por exemplo, /dev/urandom no Linux ou `BCryptGenRandom` no Windows).

Impacto Global e Casos de Uso Transformadores

A combinação do desempenho e da portabilidade do WebAssembly com a abstração segura de recursos do WASI está prestes a impulsionar a inovação em diversas indústrias globais:

1. Computação de Borda (Edge Computing) e IoT: Código Seguro em Dispositivos Restritos

Dispositivos de borda frequentemente possuem recursos limitados (CPU, memória, armazenamento) e operam em ambientes potencialmente inseguros ou não confiáveis. A baixa ocupação do Wasm e o forte modelo de segurança do WASI o tornam ideal para implantar lógica de aplicação em dispositivos de borda. Imagine uma câmera de segurança executando um módulo Wasm para inferência de IA, apenas permitido a ler do feed da câmera e a escrever dados processados em um endpoint de rede específico, sem qualquer outro acesso ao sistema. Isso garante que, mesmo que o módulo de IA seja comprometido, o próprio dispositivo permaneça seguro.

2. Funções Serverless: Multi-Tenancy de Próxima Geração

Plataformas serverless são inerentemente multi-inquilinas, executando código de vários usuários em infraestrutura compartilhada. O WASI oferece um mecanismo de sandboxing superior em comparação com contêineres tradicionais para este caso de uso. Seus tempos de inicialização rápidos (devido ao tamanho pequeno e execução eficiente) e segurança granular garantem que o código de uma função não possa interferir com outra, ou com o host subjacente, tornando as implantações serverless mais seguras e eficientes para provedores de nuvem e desenvolvedores em todo o mundo.

3. Microsserviços e Arquiteturas Poliglotas: Componentes Agnosticistas de Linguagem

Organizações estão cada vez mais adotando microsserviços, frequentemente escritos em diferentes linguagens de programação. O Wasm, compilado de praticamente qualquer linguagem, pode se tornar o runtime universal para esses serviços. A abstração do WASI garante que um serviço Wasm escrito em Rust possa interagir com segurança com arquivos ou bancos de dados tão facilmente e seguramente quanto um escrito em Go, tudo enquanto é portátil em toda a infraestrutura, simplificando o desenvolvimento e a implantação de microsserviços poliglota em escala global.

4. Blockchain e Contratos Inteligentes: Execução Determinística e Confiável

Em ambientes de blockchain, os contratos inteligentes devem ser executados de forma determinística e segura em numerosos nós distribuídos. A natureza determinística do Wasm e o ambiente controlado do WASI o tornam um excelente candidato para motores de execução de contratos inteligentes. A virtualização de descritores de arquivo garante que a execução do contrato seja isolada e não possa interagir com o sistema de arquivos subjacente do nó, mantendo a integridade e a previsibilidade.

5. Sistemas Seguros de Plugins e Extensões: Expandindo Capacidades de Aplicações com Segurança

Muitas aplicações, de navegadores web a sistemas de gerenciamento de conteúdo, oferecem arquiteturas de plugins. A integração de código de terceiros sempre acarreta riscos de segurança. Ao executar plugins como módulos Wasm habilitados para WASI, os desenvolvedores de aplicações podem controlar precisamente quais recursos cada plugin pode acessar. Um plugin de edição de fotos, por exemplo, pode ser permitido apenas a ler o arquivo de imagem que lhe é dado e a escrever a versão modificada, sem acesso à rede ou permissões mais amplas do sistema de arquivos.

Desafios e Direções Futuras para a Abstração Universal

Embora a virtualização de descritores de arquivo e a abstração de recursos do WASI ofereçam imensas vantagens, o ecossistema ainda está em evolução:

1. Padrões em Evolução: E/S Assíncrona e Modelo de Componentes

A especificação inicial do WASI, wasi_snapshot_preview1, suporta principalmente E/S síncrona, o que pode ser um gargalo de desempenho para aplicações intensivas em rede. Esforços estão em andamento para padronizar E/S assíncrona e um Modelo de Componentes mais robusto para Wasm. O Modelo de Componentes visa tornar os módulos Wasm verdadeiramente composíveis e interoperáveis, permitindo-lhes comunicar de forma segura e eficiente sem conhecer os detalhes internos uns dos outros. Isso aprimorará ainda mais as capacidades de compartilhamento e abstração de recursos.

2. Considerações de Desempenho para Virtualização Profunda

Embora o Wasm seja rápido, a camada de tradução entre as chamadas WASI e as chamadas de sistema nativas introduz alguma sobrecarga. Para aplicações de altíssimo desempenho e intensivas em E/S, essa sobrecarga pode ser uma consideração. No entanto, otimizações contínuas nos runtimes Wasm e implementações WASI mais eficientes estão continuamente reduzindo essa lacuna, tornando Wasm + WASI competitivos mesmo em cenários exigentes.

3. Amadurecimento das Ferramentas e do Ecossistema

O ecossistema Wasm e WASI é vibrante, mas ainda está amadurecendo. Melhores depuradores, profilers, integrações de IDE e bibliotecas padronizadas em diferentes linguagens acelerarão a adoção. À medida que mais empresas e projetos de código aberto investem no WASI, as ferramentas se tornarão ainda mais robustas e amigáveis para desenvolvedores em todo o mundo.

Conclusão: Capacitando a Próxima Geração de Aplicações Cloud-Native e de Borda

A virtualização de descritores de arquivo do WebAssembly WASI é mais do que apenas um detalhe técnico; ela representa uma mudança fundamental na forma como abordamos segurança, portabilidade e gerenciamento de recursos no desenvolvimento de software moderno. Ao fornecer uma interface de sistema universal baseada em capacidades que abstrai as complexidades e riscos das interações específicas do host, o WASI capacita os desenvolvedores a construir aplicações que são inerentemente mais seguras, implantáveis em qualquer ambiente, desde pequenos dispositivos de borda até grandes centros de dados na nuvem, e eficientes o suficiente para as cargas de trabalho mais exigentes.

Para um público global que lida com as complexidades de diversas plataformas de computação, o WASI oferece uma visão atraente: um futuro onde o código realmente funciona em qualquer lugar, com segurança e previsibilidade. À medida que a especificação WASI continua a evoluir e seu ecossistema amadurece, podemos antecipar uma nova geração de aplicações cloud-native, de borda e embarcadas que aproveitam essa poderosa abstração para construir soluções de software mais resilientes, inovadoras e universalmente acessíveis.

Abrace o futuro da computação segura e portátil com o WebAssembly e a abordagem inovadora do WASI para a abstração de recursos. A jornada em direção à implantação de aplicações verdadeiramente universais está bem encaminhada, e a virtualização de descritores de arquivo é a pedra angular deste movimento transformador.